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Abstract. This article shows how the operational semantics of a lan¬ 
guage like ORC can be instrumented so that the execution of a program 
produces information on the causal dependencies between events. The 
concurrent semantics we obtain is based on asymmetric labeled event 
structures. The approach is illustrated using a Web service orchestration 
instance and the detection of race conditions. 


1 Introduction 

Several languages have been proposed to program applications based on Web 
service orchestrations (BPEL [T] is probably one of the best known). The present 
work is based on Ore |2I3) . an orchestration language whose definition is based 
on a mathematical semantics, which is needed to define precisely the notion of 
causality. Ore is designed over the notion of sites, a generalization of functions 
that can encapsulate any kind of externally defined web sites or services as well 
as Ore expressions. As usual for languages, the operational semantics of Ore was 
defined as a labeled transition system. Such semantics produces naturally sets of 
sequential traces, which explicitly represent the observable behaviors of an Ore 
program [3]. 

Finding the causal dependencies in a program is very useful for error detec¬ 
tion. In a non-deterministic concurrent context, this analysis cannot be based 
solely on the static structure of the program and requires execution. Dependen¬ 
cies are also very difficult to extract from a sequential record without additional 
information to unravel the interleaving of events. This is especially true for the 
analysis of QoS or of non functional properties, like timing constraints derived 
from the critical path of dependencies . We consider any Ore program, which 
has been already parsed and expanded into its Ore calculus intermediate form. 
In this program, we distinguish the actions, which are the site calls, and the 
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publications (return values of expressions). An event is the occurrence of an ac¬ 
tion during the execution of the Ore program. The events are linked by causal 
dependencies, that force the events to be executed in a certain order. We can 
distinguish three kinds of dependencies: 

— the dependencies that are imposed by the control flow of the program de¬ 
fined by the semantics of the Ore combinators and imposed by the binding 
mechanism of Ore variables; 

— the dependencies that are provided by the server executing the site calls. 
These external dependencies are not part of the Ore description, but could 
be returned by the site. We will consider at least that the possible return of 
a site call is directly caused by this call; 

— the dependencies induced by preemption (the pruning operator of Ore). 

The method used in this article is to extend the standard structural opera¬ 
tional semantics (SOS [6]) to rewrite extended expressions, in which additional 
information has been added to compute causal and weakly-causal dependencies. 
This information is also made visible by extending the labeling of transitions. 
Concurrency is just the complement of the weak-causal relation, and conflicts 
are defined by cycles in this relation. Capturing causality and concurrency by 
instrumenting the semantics rules is a difficult job. This is mainly due to the 
fact that these relationships are global and therefore difficult to locate on the 
syntactic forms. The solution is to keep information about the causal past in a 
context associated with each rule. We build the necessary links between differ¬ 
ent contexts during the execution of rules. The aim is that such instrumented 
semantics reproduces the standard behavior of the program while calculating 
the additional information needed to track concurrency, causality and conflicts 
between the events produced by the execution. 

After this introduction, the article presents the contribution compared to 
the existing works. Section presents the Ore language from the perspective 
of its core calculus and its operational semantics, illustrated using an example 
of orchestration of Web services. Section presents our proposed instrumented 
semantics based on the construction of event structures, giving the concurrent 
semantics of Ore. This section sets out the formal correctness of the approach 
stating that this new semantics produces the same executions as the standard 
semantics. Before concluding the paper, Sectionreuses the example of Section 
[ 3 ] to show the causal structure obtained from its execution in the instrumented 
semantics and how this can be used to find errors. 

2 Related work 

The need to dynamically trace the causal dependencies during the execution of 
the a program in order to monitor, detect errors or analyze performances is well 
recognized for concurrent applications. Causality, seen as a partial order [7], can 
be tracked in different ways. Some works are based on an instrumentation of 
either the underlying operating system or the source code. For example, vector 


clocks have been widely used by the distributed algorithms community in the 
context of message-passing systems [5]. The context of Web service orchestra¬ 
tions is more complex as a language like Ore can generate unbounded concur¬ 
rency patterns. To our knowledge, the only instrumentation made on programs is 
[H], based on Java byte-code. However, in the considered model, the only source 
of causality comes from variable accesses. The second approach is to change the 
semantics so that it produces causal information which leads to a concurrent 
semantics. The challenge is then to maintain a good form of equivalence with 
the original semantics. Several debugging techniques rely on this principle, es¬ 
pecially for performing replay m is a good example for a fragment of the Oz 
language). The most successful works in concurrent semantics were conducted 
on process algebra (e.g. pi-calculus m)- Our contribution is in the same vein, 
but for the Ore language, in the complex context of wide-area computing. Other 
attempts of concurrent semantics for Ore based on event structures have already 
been published mm- They use an ad hoc connection of Petri net diagrams or 
Join calculus. It is not clear how this semantics can be implemented in practice 
at compile-time that transforms the source code into a concurrent model. An 
instrumented semantics solves this problem and allows to catch causal depen¬ 
dencies at runtime. 

3 The Ore Programming Language 

3.1 Core calculus 

Ore is a full programming language, that looks like a functional language with 
many non-functional aspects to handle concurrency. The interested reader can 
refer to m concerning the ability of Ore to design large-scale distributed appli¬ 
cations. The Ore programming language is designed over a process calculus: the 
Ore core calculus. All the conveniences offered in the full Ore language are de¬ 
rived from very few central concepts present in the calculus: sites and operators. 
Values such as booleans, numbers and strings, arithmetic and logic operators, as 
well as complex data types such as shared registers, are just external sites. Even 
choices are implemented through the use of sites ift and iff, that publish a 
signal if their argument is true or false respectively. Besides sites, four operators 
are provided by the calculus to orchestrate the execution. These operators de¬ 
scribe the sequencing of actions (“/ >x> g” ), the launching of parallel threads 
(“/|g”), an original preemption operator (“pruning: / <x< g") and an alterna¬ 
tive in case of no response (“otherwise: f',g”). The full syntax of the calculus is 
specified by the grammar given in Figure From now on, we denote by Orcg 
the set of the expressions allowed by this syntax. The expressions of the calculus 
that correspond to real Ore programs, denoted by the set Ore, are those that 
do not contain Ik and T expressions. 

There are two kinds of sites in Ore: the external ones, denoted V in the 
syntax, and the internal ones defined as an Ore expression with the syntax 
def y{x) = fij^g where / is the body of the site and g is the remaining of the 
program in which y can be used as any site. For the sake of clarity, we consider 




f,g,h £ Expression 
D £ Definition 
V £ Ore Value 
p £ Parameter 
w £ Response 
n £ Hidden Label 
I £ Label 


= P\\p{p)pk\\f\9\\f >x> g\\f <x< g\\f-,g\\D#f\\L 
= def y{x) = / 

= V\\D 
= n|jstop||a: 

= NT{v)\\nv)\\Neg 
= Wu{v)\\lD\\h{uj)\\h{\v) 

= !ii||n||a; 


Fig. 1. The syntax of the Ore core calculus. 


in this work that the sites are curryfied, so they have exactly one argument. Site 
definitions are recursive, which allows the same expressivity as any functional 
language. Calls to external sites are strict, i.e. their arguments have to be bound 
before the site can be called, while an internal site can be called immediately, and 
its arguments are evaluated lazily. When an external site is called, it sends its 
responses to a placeholder 7k. A response can be either a non-terminating value 
NT(v) if further responses are expected, or a terminating value T{v) if this is 
the last publication of the site, or Neg if the site terminates without publishing 
any value. In f\g, the parallel composition expresses pure concurrency; / and g 
are run in parallel, their events are interleaved and the expression stops when 
both / and g have terminated. Sequentiality can be expressed by the sequential 
operator, like in f >x> g, where the variable x can be used in g. Here, / is 
started first, and then a new instance of g[v/x ], where x is bound to v, is launched 
as a consequence of each publication of v. In f <x< g, the pruning operator 
is used to express preemption. The variable x can be used in /. Both / and g 
are started, but / is paused when it needs to evaluate x. When g publishes a 
value, it is bound to x in /, and g is stopped. Other events that could have been 
produced by g are preempted by the publication. For example, if g is supposed 
to publish two values a and 6, only one will be selected and published in each 
execution. We say that these two events are in conflict. The pruning operator 
is left-associative: inf<x<g<y<h, f,g and h are started in parallel, the 
first publication of g is bound to x and the first publication of h is bound to y. 
The otherwise operator is used in f;g. In this expression, / is first started alone 
and g is started if and only if / stops without publishing any value. Finally, the 
stop symbol can be used by the programmer exactly like a site or a variable 
to denote a terminated program, stop still produces an event oj to notify its 
parent expression that it has terminated. It then evolves into T, the inert final 
expression. 7k and T cannot be used directly. 


3.2 Illustration 

We now illustrate the use of Ore in Figure This program defines the in¬ 
ternal site find_best (agencies, destination) that computes the best offers 
proposed by the agencies listed in agencies for the destination given as a pa¬ 
rameter. It publishes a unique value that is a pair composed of the best offer 
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Fig. 2. The rules of the operational semantics. 


augmented with additional information and the list of other offers sorted by 
price. The program is composed of three internal sites. It uses three shared 
objects, that are created in lines 15 to 17: the stack offers and the registers 
best_offer and best_agency. At line 16, a new register is created through 
a call to the site Register () and is bound to the variable r. It is then ini¬ 
tialized to a default value: r. write (null) that can be seen as a shortcut for 
r("write")>w>w(null), so the shared register is a site that can publish its ac¬ 
cessors when it is called. As writing in a register does not publish any value, 
the otherwise operator is finally used to bound the value to best_offer. At line 
11, the site find_offers can be started before the variables are created (left 
hand side of pruning operators), each publishes in parallel all the sites contained 
into the stack agencies, so all known agencies have to publish their offers. Each 



1 def find-best (agencies, destination) = 

2 def find_offers() = 

3 each(agencies) > agency > agency(destination) > offer > 

4 (offers.add((offer, agency)) | 

5 (best_offer.read() > o > compare(o, offer) > b > 

6 ift(b) > X > (best-agency.write(agency) | best-offer.write(offer)))) ^ 

7 def extend_best() = 

8 best_agency.read() > ba > best_offer.read() > bo > ba.exists(bo) > b > 

9 (ift(b) > X > ba.get Jnfo(bo) | iff(b) > x > alarm (’’inconsistent”)) # 

10 def sort_offers(offers, best_offer) = 

11 offers.sort(); best_offer.read() = offers.first() >b> 

12 (ift(b) > X > offers | iff(b) > x > alarm(”not best”)) ^ 

13 ((t <t< (find_offers() | timer(2000))) > t > 

14 ((o-b, s_o) <e_b< extend_best() <s_o< sort .offers ())) 

15 <offers< Stack() 

16 <best_offer< (Register() >r> r.write(null); r) 

17 <best_agency< Register() # 

Fig. 3. Identification of the best offers for a destination proposed by a pool of 
agencies. 


time a new offer is found, it is added into offer and its price is compared to the 
current best known offer. The test is first evaluated and passed as an argument 
to ift. If true, the program publishes a signal and the registers can be updated. 
find_offers does not publish any value. In parallel with its call, we start a 
timer that publishes after 2 seconds a signal. The signal will halt this part of 
the program thanks to the pruning operator, and starts the line 14, thanks to 
the sequential operator. Line 14 calls both extend_best and sort_offers and 
publishes the result when both sites have published. The two sites call an exter¬ 
nal site either to sort the offers or to get extra information about the best offer, 
and they perform a test that raises an alarm if something wrong is detected. 

Figure shows a possible trace of the program of Figure In this example, 
both alarms are due to inconsistencies in the shared registers. To avoid the alarm 
“inconsistent”, it is necessary to write into best_offer and best_agency atom¬ 
ically, and to avoid the other alarm, the comparison with the current value of 
best_offer and its edition should be atomic. The event best_offer. write (01) 
is a cause for both alarms, but it is impossible to detect it in the sequential trace 
without any information about causality. 

4 Instrumented Semantics 

4.1 Method 

SOS specifications take the form of a set of inference rules that define the valid 
transitions of a composite piece of syntax in terms of the transitions of its com¬ 
ponents. Rewriting transforms terms by executing a rule (it may be a non- 


1. each([Al, A2]) 

2 . timer(2000) 

3. new_register() 

4. new_register() 

5. A1(D) 

6 . r.write(null) 

7. best_offer.read() 

8 . new_stack() 

9. offers.add(Ol) 

10. A2(D) 

11 . offers.add(02) 


12 . compare(null, 01) 

13. best_offer.read() 

14. compare(null, 02) 

15. ift(true) 

16. iff (true) 

17. best_offer.write(02) 

18. best_offer.write(01) 

19. best_agency.write(Al) 

20. best_agency.write(A2) 

21 . best_agency.read() 

22 . best_offer.read() 


23. A2.exists(01) 

24. iff(false) 

25. ift(false) 

26. alarm( “inconsistent”) 

27. offers.sort 0 

28. best_offer.read() 

29. offers.first() 

30. =(01, 02) 

31. iff(false) 

32. ift(false) 

33. alarm(“not best”) 


Fig. 4. A possible execution for the program in Figure where agencies = 
[Al, A2] and destination = D. Each agency publishes an offer Ol and 02 respec¬ 
tively. For the sake of space and clarity, we only show site calls in this execution. 

deterministic transition in case of multiple alternatives). The successive transi¬ 
tions represent the program behavior. This may produce a sequence of values, 
that can be brought by the labeling of rules. Our approach is based on an in¬ 
strumentation of the rules, that appends additional information to the labels in 
order to track the partial order of events. Actually, a label in the instrumented 
semantics is a tuple e = (e^, e;, Cc, e^), where e/j is an identifier taken in a count¬ 
able set K, that is unique for the execution, e; is a label similar to those of the 
standard semantics and Cc and Sa contain the finite sets of the identifiers of the 
causes and the weak causes of the event, respectively. Informally, an event e is 
a cause of e' if e always happens before e', regardless of the scheduling chosen 
by the system. Similarly, e is a weak cause of e' if e' can never happen after e, 
either because e is one of its causes or because e' preempts e. 

In order to record the information concerning the past of an expression, we 
enrich the language with a new syntactic construction: (/, c, a) l means that c 
and a are the causes of the Ore instrumented expression /. Thus, if / has c and 
a as causes and if it can evolve into /', this transition should also have c and a 
as causes. The index L expresses the kind of events that can activate the rule: 
!u matches any publication, I stands for any label and uj means that c and a 
are only the causes of the termination of the program. We also consider that 
the external sites track causality themselves, as an internally-defined function 
would do. It makes sense as some sites (e.g. -f) handle their calls independently, 
while others (e.g. shared registers, management library) induce more complex 
causality patterns between the calls. Hence, the responses we get include this 
additional information. The verification of these responses is not the subject 
here, and we suppose them to be correct by hypothesis. 

Apart from the introduction of the instrumentation construction and the new 
information in the responses, the syntax of the instrumented expressions (Figure 
is very similar to the regular one. The set of all the expressions allowed by 
this extended syntax is OrCi. We can notice that every valid Ore program is also 


f,g,h £ Expression 


D € Definition 
V € Ore Value 
p € Parameter 
w € Response 

n € Hidden Label 
I € Label 


■■■- p\\p{p)\\7k\\f\g 

11 / >x> g\\f <x< g\\f;g 
\\D#f\\±\\{f,K,K)L 

def y{x) = f 
V|1D 

::= n||stop||x||(p,R', K)l 
::= NT(v,K, K)\\T{v,K,K) 
\\Neg{K,K) 

::= 7V,{v)\\7D\\hH\\h{\v) 


Fig. 5. The extended syntax of the instrumented semantics. 


a valid instrumented expression, which means that the instrumented semantics 
can be applied without program transformation. 

4.2 Labeled Asymmetric Event Structure 

Labeled asymmetric event structures (LAES) [15] are natural objects to repre¬ 
sent concurrent executions in a compact way. 

Definition 1 (Labelled asymmetric event structure). A labelled asym¬ 
metric event structure (LAES) is a tuple (E, L, <,/*, d). 

— E is a set of events, 

— L is a set of labels, 

— <, causality is a partial order on E, 

— weak causality is a binary relation on E, 

— A ■. E ^ L is the labelling function, 

— each e G E has a finite causal history [e] = {e' € E\e' < e}, 

— for all events e < e' G E, e e', where < is the irreflexive restriction of <, 

— for all e € E, ^ n[e] X [e], the restriction of weak causality to the causal 

history of e, is acyclic. 

We also define an induced conflict relation ffa as the smallest set of finite 
parts of E such that: for E' C E and eo, ei,..., e„ G E, 

— if eo ei /* • • • Z* e„ eo then {eo, ei, • • • , e„} G #o, 

— if E' U {eo} G #a and eo < ei then E' U {eij G ffa- 

Informally, two events are in conflict if they cannot occur together in the same 
execution. 

A LAES can be seen as a structure that encodes concisely several sequential 
executions; each of them being a linearization of the LAES. 

Definition 2 (Linearization). Let £ = {E^L,<, /^,A) be a LAES. A finite 
linearization of £ is a word w = d(eo)... d(e„) where the different G E are 
distinct and such that: 
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f -/ 
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I ^ L 


Fig. 6. The semantics of the new operator (/, c, a) ^ is defined by two additional 
rules. 


— it is left-closed for causality: 

Ve G if, Ve' G {eo,..., e„}, e < e' ^ e e {eo,..., e„}, 

— the weak causality is respected: 

Vi, j G {0,..., n}, a /■ Cj ^ i < j. 

We denote Lin{£) as the set of all finite linearizations of £. 

Let {E,L,<, /',A) be an asymmetric event structure and e,e' G E two 
events. We say that: 

— e is a cause of e', if e happens before e! in all executions; 

— e is a weak cause of e', if there is no execution in which e happens after e'; 

— e and e' are concurrent, denoted e||e', if they can occur in either order. 
Formally, e||e' if neither e ^ e' nor e' e. 

— e is preempted by e!, denoted e e', if e' can occur independently from 

e, but after that, e cannot occur anymore. Formally, e if e yA e! and 

e ^ e!. 

4.3 Rules 

Essentially, the instrumented semantics presented in Figure [^decorates the rules 
of standard semantics, except that two rules are added (see Figure |^. The 
transition system defined by this instrumented semantics is denoted —and the 
sequential executions starting from a program / are contained in the set |/]i. 

Informally, the expression (/, c, a)i evolves exactly like /, but some causes 
and weak causes may be added to the event. For example, if L =!z; and / 
produces an internal event, that is not a publication, only the rule CauseNo 
can be applied, so the instrumentation will have no effect. On the other hand, 
if / publishes a value, the rule CauseYes applies and c and a are added to the 
causes and weak causes of the publication. Note that c is also added to the weak 
causes. This is to ensure that causality is always a special case of weak causality. 

Let us now comment the most relevant instrumentations of the other rules. 
Let us consider rule SeqV. When a value is published, a new instance of the 
right hand side expression is created. All the events produced by this new ex¬ 
pression need the former publication to have occurred before them, i.e. they are 
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Fig. 7. The instrumented version of the rules of the operational semantics. 



consequences of this publication. This is why the new expression is instrumented. 
Even if PruneV and SeqV are syntaxically very similar in their standard forms, 
the fact that both hand sides of the pruning operator are run in parallel makes 
them very different in terms of causality. In the expression (fix) <x< 2, the 
second publication of 2 is a consequence of the first one, but not the publication 
of I. This is why the instrumentation covers the occurrences of the newly bound 
variable. However, this is not sufficient. Consider the program (stop <x< 2); 3. 
The publication of 3 must wait the end of the left hand side (i.e the publication 
of 2). However, this publication is useless, in the sense that no variable x can 
be bound to its value. To handle this case, we add an instrumentation to the 
whole expression that is only triggered when the expression stops. Finally, the 
rule PruneN is also interesting as it generates weak causality. Indeed, in the 
program x <s< ((I + 1)|3), the left hand side can call site + and then publish 
3, or publish 3 directly, but can never publish 3 and then call site +, because 
a publication preempts any other event. Of course, it could also wait for the 
answer of the site and then publish 2, which would preempt the publication of 
3. This preemption relation is operated by an instrumentation that contains k 
as weak causes and that is triggered only in case of publication. 


4.4 Concurrent executions 

The equivalent of traces in the instrumented semantics are the concurrent exe¬ 
cutions, represented by LAES. 

Definition 3 (Concurrent execution). Let a = . ..a'^ G |/oli, where for 

all i, cr* = (crl,ai, cr^, tr®). We define the concurrent execution of a as the LAES: 

^ = iWk, • ■ •. }> Wi,---, <}. <, ^) 

where for all i,j € {1 ,... ,n}: 

- cr(, < al ifal e ori=j, 

- ^f<^k e cri, 

- Mcrl)=al 

As the fields cr® and cr® only contain events that happened before cr® in the 
sequential execution, both < and ^ are order relations and every event has 
a finite causal history. For the same reason, is acyclic. Moreover, it is easy 
to check that weak causality is more general than causality, so this definition 
actually corresponds to a real LAES. 

We now state the main result: the behavior of a program is preserved by the 
instrumented semantics. It is established through two properties. The first one 
justifies the name of the instrumented semantics and the second one proves that 
the instrumentation is correct, i.e. that it does not define incorrect behaviors. 
Note that we do not give a complete proof of the two propositions for lack of 
space, but it can be found in [16]. 


Proposition 1 (Instrumentation). The projections of the executions pro¬ 
duced hy the instrumented semantics on their labels correspond exactly to the 
executions of the standard semantics: 

V/ e Orc,{al...a]^\a G |/]J = |/]. 

In other words, it is always possible to instrument a standard execution to get a 
concurrent execution, and conversely we can get a standard execution from an 
instrumented execution by a simple projection. 

The proof of this property is straightforward since both semantics contain sim¬ 
ilar rules. The only difficulty comes from the applications of CauseYes and 
CauseNo, that slightly modifie the structure of the derivation trees. All in all, 
both executions are similar. 

Proposition 2 (Correctness). The linearizations that can be inf erred from an 
execution in the instrumented semantics are correct with respect to the standard 
semantics: 

V/ G Orc,Vcr G lfji,Lin{W) C |/]. 

This proof is much more complicated. Let us consider a linearization L G Linifj). 
To prove that L G |/], we show that it is possible to progressively transform 
into L by applying a series of small steps that correspond either to the 
inversion of two consecutive concurrent events, to the preemption of an event by 
its successor or to a prefixation of the sequence. As (T/...cr" G |/] and each step 
preserves this property, we get that L G |/]. The main difficulty concerns the 
proof of the correctness of the two first steps, as it requires a proof for all pairs 
of possible consecutive rules. 

By introducing concurrency and preemption between events that were arbi¬ 
trarily ordered by the standard semantics, the instrumented semantics gathers 
many sequential executions into one concurrent execution, which hugely reduces 
the number of different executions. However, all the events contained in a concur¬ 
rent execution are also contained into a single sequential execution. Therefore, 
no instrumentation is able to capture conflict, as two conflictual events would 
never occur together. This is why completeness cannot be achieved with this 
approach. 

5 Application 

Let us reuse the example presented in Sectionand the execution of Figure]^ 
Figure shows the trace augmented with the causal information gained by the 
instrumented semantics. 

Figure shows the LAES in its graphical form. Events taht correspond to 
site calls are represented in circles and connected by three kinds of arrows. Direct 
causality is hgured by solid and dashed arrows. Solid arrows represent program 
causality, that is specified by the instrumented semantics, while dashed arrows 


(1, h, 0, 0) 

(2, l2, 0, 0) 

(3, k, 0, 0) 

(4, k, 0, 0) 

(5, h, {1}, {1}) 

(6, k, {4}, {4}) 

(7, k, {1,4-6}, {1,4-6}) 

(8, k. 0, 0) 

(9, k. {1,5,8}, {1,5,8}) 

(10, ho, {!}, {!}) 

(11, hi, {1,8,10}, {1,8,10}) 

(12, h2, {1,4-7}, {1,4-7}) 

(13, ho, {1,4,6,10}, {1,4,6,10}) 

(14, hi, {1,4,6,10,13}, {1,4,6,10,13}) 

(15, ho, {1,4-7,12}, {1,4-7,12}) 

(16, ho, {1,4,6,10,13,14}, {1,4,6,10,13,14}) 
(17, h7, {1,4,6,10,13,14,16}, 

{1,4,6,10,13,14,16}) 
(18, hs, {1,4-7,12,15}, {1,4-7,12,15}) 

(19, ho, {1,3-7,12,15}, {1,3-7,12,15}) 

(20, ho, {1,3,4,6,10,13,14,16}, 

{1,3,4,6,10,13,14,16}) 


(21, ki, {2}, {2, 1}) 

(22, I 22 , {1-7,10,12-16,19-21}, 

{1-7,10,12-16,19-21}) 
(23, ko, {1-7,10,12-19,22}, 

{1-7,10,12-19,22}) 
(24, ki, {1-7,10,12-19,22,23}, 

{1-7,10,12-19,22,23}) 
(25, ko, {1-7,10,12-19,22,23}, 

{1-7,10,12-19,22,23}) 
(26, ko, {1-7,10,12-19,22-24}, 

{1-7,10,12-19,22-24}) 

(27, k7, {2}, {2, 1}) 

(28, ks, {1,2,5,9-11,27}, {1,2,5,9-11,27}) 
(29, ko, {1,2,5,9-11,27}, {1,2,5,9-11,27}) 
(30, ko, {1,2,4-7,9-18,27-29}, 

{1,2,4-7,9-18,27-29}) 
(31, / 31 , {1,2,4-7,9-18,27-30}, 

{1,2,4-7,9-18,27-30}) 
(32, k2, {1,2,4-7,9-18,27-30}, 

{1,2,4-7,9-18,27-30}) 
(33, ko, {1,2,4-7,9-18,27-31}, 

{1,2,4-7,9-18,27-31}) 


Fig. 8. An execution augmented with causal information. Numbers refer to the 
events of Figure]^ 


represent data causes, that are managed by the sites themselves. A call to a 
write on a site is a cause of the publications of the next read on this site, so 
the write is a cause of all the consequences of the read. Moreover, preemption is 
figured by dotted arrows. The call to eachO — and all its consequences — is 
preempted by the publication made by timer (2000) — and all its consequences. 

Root causes analysis. This execution concurrently raises two alarms. Let us 
consider their last common causes, i.e. the events that are causes of both alarms, 
and that are not causes of another such event. The alarms have two last common 
causes: timer(2000) and best_offer.write(01). The timer is not to blame 
here, as it has no causes and is just used as a starter for the program. Indeed, 
best_offer. write (01) is the root cause for these two alarms. If this event did 
not exist, the value published by best_of f er. readO would be 02 for both calls, 
A2. exists (02) and =(02, 02) would be true and no alarm would be raised. 

Detection of Race Conditions. We can see that the events best_offer .write (01) 
and best_off er. write (02) are concurrent, as well as best_agency. write (01) 
and best_agency. write (02). In this context, these events can interleave so that 
best_offer and best_agency get inconsistent values. 



Fig. 9. Corresponding LABS in a graphical form. 


6 Conclusion 

We based our work on the Ore core calculus, as it is expressive enough to easily 
generate many situations found in distributed systems, such as causality, con¬ 
currency and preemption, and remains simple enough to be tractable in a formal 
work. Our contribution consists of an instrumentation of the standard structural 
operational semantics of Ore that tracks causality and weak causality at run¬ 
time to build LABS, well suited to represent concurrent executions. We think 
LABS are an interesting tool to access important properties of orchestrations. 
We illustrate this point on two questions: root cause analysis and detection of 
race conditions. Beyond the Ore language, we think that the article presents a 
general approach that can be used for other non-deterministic languages with 
concurrency operators. Based on this work, we think it is possible to produce 
the same information using a source to source transformation. Such a technique 
would be easier to implement, as it does not require to modify the execution 
engine of the language. 
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